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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document defines the Radio Network Layer user plane protocol being used over the lu interface. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 25.401: '"i"^ Generation Partnership Project (3GPP) Technical Specification Group 
(TSG) RAN; UTRAN Overall Description". 

[2] 3GPP TS 25.410: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; UTRAN lu interface: general Aspects and Principles". 

[3] 3GPP TS 25.413: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; UTRAN lu interface RANAP protocol". 

[4] 3GPP TS 25.414: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; lu Interface Data Transport and Transport Signalling". 

[5] 3GPP TS 23. 110: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) SSA, UMTS Access Stratum, services and functions". 

[6] 3GPP TS 23.121: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) SSA, Architectural requirements for Release 99". 

[7] ITU-T Recommendation 1.363.2 (1 1/2000): "B-ISDN ATM Adaptation Layer type 2 

specification". 

[8] ITU-T Recommendation 1.366.1 (1998): "Segmentation and reassembly service specific 

convergence sublayer for the AAL type 2". 

[9] 3GPP TR 25.990: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; Vocabulary". 

[10] 3GPP TS 25.321: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; MAC Protocol Specification". 

[II] 3GPP TS 25.322, 3"* Generation Partnership Project (3GPP) Technical Specification Group (TSG) 
RAN; RLC Protocol Specification. 

[12] 3GPP TS 26.102: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) SA; Mandatory speech codec; AMR speech codec; Interface to lu and Uu". 

[13] 3GPP TS 23.153: "3"* Generation Partnership Project (3GPP) Technical Specification Group Core 

Network; Out of Band Transcoder Control - Stage 2". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

lu Timing Interval (ITI): lu Timing Interval is the minimum time interval between sent lu UP PDUs for a specific 
RAB. The ITI can be calculated for conversational and streaming traffic classes by the following formula: 

_ MaxSDUsize 
MaxBitrate 

Inter PDU Transmission Interval (IPTI): Inter PDU Transmission Interval is the actual interval at which lu UP PDUs 
can be sent at a certain time for a specific RAB subflow combination. The IPTI of a RAB subflow combination is 
calculated based on the RAB subflow combination size and the RAB subflow combination bitrate by dividing the RAB 
subflow combination size with the RAB subflow combination bitrate. 

RFC _ size 

IPTI = — , g = l,...,n, n = number of subflowcombinations 

^ RFC Bitrate 



NOTE: If RFC_Bitrate is not defined then IPTI=ITI. If RFC_size is not defined then RFC_size=MaxSDUsize. 

Non Access Stratum (NAS) Data Streams: non Access Stratum Data Streams is a generic term to identify these data 
streams exchanged at the Dedicated Service Access Points between the Non Access Stratum and the Access Stratum. 

RAB sub-flows: RAB as defined in [9] is realised by UTRAN through one to several sub-flows. These sub-flows 
correspond to the NAS service data streams that have QoS characteristics that differ in a predefined manner within a 
RAB e.g. different reliability classes. 

RAB sub-flows characteristics: 

1) the sub-flows of a RAB are established and released together at the RAB establishment and release, respectively; 

2) the sub-flows of a RAB are submitted and delivered together at the RAB SAP; 

3) the sub-flows of a RAB are carried over the same lu transmission connection; 

4) the sub-flows of a RAB are organised in a predefined manner at the RAB SAP and over the lu interface. The 
organisation is imposed by the NAS as part of its co-ordination responsibility. 

RAB sub-flows numbering (applies to support mode for predefined SDU size only): 

1) RAB sub-flows are numbered from 1 to N (N is the number of sub-flows); 

2) RAB sub-flow number 1 corresponds to the highest reliability class and the RAB sub-flow number N 
corresponds to the lowest reliability class; 

3) RAB sub-flows order inside the lu frame is predefined so that RAB sub-flow number one comes first and the 
RAB sub-flow number N comes last. 

RAB sub-Flow Combination (RFC): RAB sub-flow combination is defined as an authorised combination of the RAB 
sub-flows variable attributes (e.g. SDU sizes) of currently valid RAB sub-flows that can be submitted simultaneously to 
the lu UP for transmission over lu interface. Each combination is given by the CN and cannot be altered by the SRNC. 

RAB sub-Flow Combination Indicator (RFCI): this indicator uniquely identifies a RAB sub-flow combination for 
the duration of the lu UP peer protocol instances i.e. it is valid until the termination of the call or until a new 
initialisation is performed. Usage of RFCI applies only to lu UP protocol operated in support mode for predefined SDU 

size. 
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Principles related to RFCI allocation and initialisation procedure: 

1) RPCI value is present in every lu user frame; 

2) in the Initialisation procedure in lu UP, the size of every RAB sub-flow SDU for each RFCI is signalled. 

Syntactical error: field is defined to be syntactically incorrect in a message if it contains at least one value defined as 
"reserved", or if its value part violates syntactic rules given in the specification of the value part. However it is not a 
syntactical error that a value specified as "spare" is being used. 

Semantical error: message is defined to have semantically incorrect contents if it contains information which, possibly 
dependant on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AMR Adaptive Multi-Rate codec 

AS Access Stratum 

BER Bit Error Rate 

CN Core Network 

DS Data Service 

DTX Discontinuous Transmission 

DU Data Unit 

GF Galois Field 

IPTI Inter PDU Transmission Interval 

ITI lu Timing Interval 

NAS Non Access Stratum 

PCE Procedure Control Extension 

PDU Protocol Data Unit 

PME Procedure Control Bitmap Extension 

QoS Quality of Service 

RAB Radio Access Bearer 

RANAP Radio Access Network Application Part 

RFC RAB sub Flow Combination 

RFCI RFC Indicator 

RNL Radio Network Layer 

SAP Service Access Point 

SDU Service Data Unit 

SID Silence Insertion Descriptor 

SMpSDU Support Mode for predefined SDU size 

SRNC Serving RNC 

SRNS Serving RNS 

SSSAR Service Specific Segmentation and Reassembly 

TFCI Transport Format Combination Indicator 

TFI Transport Format Identification 

TFO Tandem Free Operation 

TNL Transport Network Layer 

TrFO Transcoder Free Operation 

TrM Transparent Mode 

UP User Plane 

UUI User to User Information 

3.3 Concepts 

lu UP mode of operation: 

One objective of the lu User Plane (UP) protocol is to remain independent of the CN domain (Circuit Switched or 
Packet Switched) and to have limited or no dependency with the Transport Network Layer. Meeting this objective 
provides the flexibility to evolve services regardless of the CN domain and to migrate services across CN domains. 
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The lu UP protocol is therefore defined with modes of operation that can be activated on a RAB basis rather than on a 
CN domain basis or (tele) service basis. The lu UP mode of operation determines if and which set of features shall be 
provided to meet e.g. the RAB QoS requirements. 

lu UP protocol PDU Type: 

The lu UP protocol PDU Types are defined for a given lu UP mode of operation. An lu UP PDU Type represents a 
defined structure of an lu UP protocol frame. For instance, a frame made of a certain Frame Header mask part and a 
Frame Payload part would be specified as a certain PDU type valid for a given lu UP mode of operation. 

Tandem Free Operation (TFO): 

Configuration of a Speech or Multimedia call for which Transcoders are physically present in the communication path 
but transcoding functions are disabled or partially disabled. The Transcoders may perform control and/or protocol 
conversion functions. 

Transcoder (TC): 

Physical device present in the network responsible for the transcoding of the speech data between two speech codecs or 
coding schemes (The Transcoder may also include other functions, i.e. Rate Adaptation in GSM). 

Transcoder Free Operation (TrFO): 

Configuration of a Speech or Multimedia call for which Transcoders are not present in the communication path. 



4 General 

4.1 General aspects 

The lu UP protocol is located in the User plane of the Radio Network layer over the lu interface: the lu UP protocol 
layer. 

The lu UP protocol is used to convey user data associated to Radio Access Bearers. 

One lu UP protocol instance is associated to one RAB and one RAB only. If several RABs are established towards one 
given UE, then these RABs make use of several lu UP protocol instances. 

In general, lu UP protocol instances exist at lu access point as defined [2] i.e. at CN and UTRAN. However, as 
described in [13], if TrFO is possible and the lu UP protocol instances operate in support mode the lu UP protocol 
instance in CN may resume performing lu UP specific functions or vanish completely during stable call states. In this 
case the partner peer entity actually interacting with the UTRAN lu UP protocol instance (i.e. performing all lu UP 
specific functions except UP initialisation) may either be located within another UTRAN or within a CN node that is 
not the serving CN node of the UTRAN. 

Whenever a RAB requires transfer of user data in the lu UP, an lu UP protocol instance exists at each lu interface 
access points. These lu UP protocol instances are established, relocated and release together with the associated RAB. 

Whether these peer protocol instances perform some RAB related function depends on the mode of operation of the lu 
UP as defined below. 

The following figure illustrates the logical placement of the lu UP protocol layer and the placement of the Data Streams 
sources outside of the Access Stratum. 
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Figure 1 : lu UP protocol layer occurrence in UTRAN overall architecture (User Plane View) 

4.2 Operational and Functional Aspects 

4.2.1 lu UP protocol modes of operation 

The lu UP protocol operates in mode according to the concept described in earHer subclause. 
Modes of operation of the protocol are defined: 

1) Transparent mode (TrM); 

2) Support mode for predefined SDU size (SMpSDU). 

Determination of the lu UP protocol instance mode of operation is a CN decision taken at RAB establishment based on 
e.g. the RAB characteristics. It is signalled in the Radio Network layer control plane at RAB assignment and relocation 
for each RAB. It is internally indicated to the lu UP protocol layer at user plane establishment. 

The choice of a mode is bound to the nature of the associated RAB and cannot be changed unless the RAB is changed. 

4.2.2 Transparent mode (TrM) 

The transparent mode is intended for those RABs that do not require any particular feature from the lu UP protocol 
other than transfer of user data. 

The following figure illustrates the transparent mode of operation of the lu UP protocol layer. 
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Figure 2: lu UP protocol layer in transparent occurrence over lu interface 

In this mode, the lu UP protocol instance does not perform any lu UP protocol information exchange with its peer over 
the lu interface: no lu frame is sent. The lu UP protocol layer is crossed through by PDUs being exchanged between 
upper layers and transport network layer. 

For instance, the transfer of GTP-U PDUs could utilise the transparent mode of the lu UP protocol. 

4.2.3 Support mode 

The support modes are intended for those RABs that do require particular features from the lu UP protocol in addition 
to transfer of user data. When operating in a support mode, the peer lu UP protocol instances exchange lu UP frames 
whereas in transparent mode, no lu UP frames are generated. 

The following figure illustrates the functional model of the lu UP protocol layer in support mode of operation. 
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Figure 3: lu UP protocol layer in support mode occurrence over lu interface 
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Some RABs requesting lu UP protocol support, constrain the lu UP protocol and possibly the radio interface protocols 
in specific ways. For instance, certain RABs can have variable predefined rates. 

The lu UP support mode is prepared to support variations. 

The only support mode defined here is the: 

Support mode for predefined SDU size (SMpSDU). 

For instance, the transfer of AMR speech PDUs would utilise the support mode for predefined SDU size of the lu UP 
protocol because it requires some procedure control functions and some data streams specific functions while the sizes 
of the user data being transferred can vary in a predefined manner. 

5 Transparent mode, version 1 

5.1 General 

5.1 .1 Operation of the lu UP in Transparent mode 

The lu UP layer in transparent mode is present in the lu User plane for transferring data transparently over the lu 
interface. 

The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer. 

5.1 .2 Interfaces of the lu UP protocol layer in Transparent mode 

Interfaces of the lu UP protocol layer in transparent mode are the transport network layer and the upper layers. The lu 
UP protocol layer in transparent mode is an empty layer through which NAS Data Streams PDUs are crossing between 
the Transport Network Layer and upper layers. 

The lu UP protocol layer in transparent mode is using services of the Transport layers in order to transfer the lu UP 
PDUs over the lu interface. 

5.2 lu UP Protocol layer Services in Transparent mode 

The following functions are needed to support this mode: 
Transfer of user data. 

5.3 Services Expected from the UP Data Transport layer 

The lu UP protocol layer in transparent mode expects the following services from the Transport Network Layer: 
Transfer of user data. 
Delivery of SDUs in sequence when requested by the RAB parameter 'Delivery Order' [3]. 

5.4 Elements for lu UP communication in Transparent mode 
5.4.1 Frame Format for transparent mode 

The following shows the format of the PDU crossing the lu UP protocol layer in transparent mode. This frame is 
transferred transparently between the lu UP protocol upper layers and transport network layer (TNL-SAP). 
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Oct1 



Octn 



Figure 4: Frame format for transparent mode 

This PDU has a variable length of n octets, whose maximum range depends on the type of user data (e.g. IP packet). No 
explicit length indication is visible at the lu UP protocol layer. 



Support mode for predefined SDU sizes, version 2 



6.1 



General 



6.1 .1 Operation of the lu UP in Support mode 

The lu UP protocol layer in Support mode is present for data streams that need frame handling in the UP. 

The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer. 

6.1 .2 Interfaces of the lu UP protocol layer in Support mode 

As part of the Access Stratum responsibility, the lu UP protocol layer in support mode provides the services and 
functions that are necessary to handle non access stratum data streams. The lu UP protocol layer in support mode is 
providing these services to the UP upper layers through a Dedicated Service Access Point used for Information Transfer 
as specified in [5]. 

The lu UP protocol layer in support mode is using services of the Transport layers in order to transfer the lu UP PDUs 
over the lu interface. 

6.2 lu UP Protocol layer Services in Support mode 

Support mode for predefined SDU size Service 

The following functions are needed to support this mode: 
Transfer of user data; 
Initialisation; 
Rate control; 
Time alignment; 
Handling of error event; 
Frame quality classification. 
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6.3 Services Expected from the UP Data Transport layer 

The lu UP protocol layer in Support Mode expects the following services from the Transport Network Layer: 
Transfer of user data. 
Delivery of SDUs in sequence when requested by the RAB parameter 'Delivery Order' [3]. 



6.4 

6.4.1 



Functions of the lu UP Protocol Layer in Support mode 
Functional model of the lu UP Protocol Layer in Support mode 
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Figure 5: Functional model of the lu UP protocol layer in Support mode 

The lu UP protocol layer in Support mode is made of three sets of functions: 

1) Frame Handler function; 

2) Procedure Control functions; 

3) Non Access Stratum Data Streams specific functions. 

6.4.2 Frame Handler function 

This function is responsible for framing and de-framing the different parts of an lu UP protocol frame. This function 
takes the different parts of the lu UP protocol frame and set the control part field to the correct values, including the 
handling of the frame number. It also ensures that the frame control part is semantically correct. This function is 
responsible for interacting with the Transport layers. This function is also responsible for the CRC check of the lu UP 
frame header. The lu UP frame with header CRC check error is discarded. 

6.4.3 Procedure Control functions 

This set of functions offers the control of a number of procedures handled at the lu UP protocol level. These functions 
are responsible for the procedure control part of the lu UP frames. 

Namely, these procedures are: 
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Rate Control: is the procedure which controls over the lu UP the maximum rate that is allowed to be sent 
downlink among the rates that can be controlled. The set of rates is represented by RFCI indicators. The function 
controlling this procedure interacts with functions outside of the lu UP protocol layer. 

Initialisation: is the procedure which controls the exchange of initialisation information that is required for 
operation in support mode for predefined SDU size. Such information can contain the RFCI Set to be used until 
termination of the connection or until the next initialisation procedure. This procedure is also used for 
negotiating the version of the lu UP Mode requested for the related RAB. 

Time Alignment: is the procedure that controls the timing of the downlink data to the RNC over lu. The 
function controlling this procedure interacts with functions outside of the lu UP protocol layer. 

Handling of Error Event: is the procedure that controls the information exchanged over the lu related to 
detection of a fault situation. The function controlling this procedure interacts with functions outside of the lu 
UP protocol layer. 

6.4.4 Non Access Stratum Data Streams specific function(s) 

These functions are responsible for a "limited manipulation" of the payload and the consistency check of the frame 
number. If a frame loss is detected due a gap in the sequence of the received frame numbers (for a RAB where frame 
numbers does not relate to time), this shall be reported to the procedure control function. These functions are 
responsible for the CRC check and calculation of the lu UP frame payload part. These functions are also responsible for 
the Frame Quality Classification handling as described below. 

These functions interact with the upper layers by exchanging lu data stream blocks of lu UP frame payload. These 
functions also handles the padding and depadding of the lu UP frame payloads when needed. 

These functions interact with the procedure control functions. 

These functions provide service access to the upper layers for the procedure control functions. 



6.4.4.1 Frame Quality Classification function 



6.4.4.1.1 General 



On the lu UP in Support Mode the frames are classified with the Frame Quality Classifier (FQC). This classifying is 
based on the radio frame classification and the setting of the RAB attributes 'Delivery of erroneous SDUs'. The RAB 
attribute 'Delivery of erroneous SDUs' tells if erroneous frames shall be delivered or not. 

Figure 6 below shows the main input and output information for frame quality classification function on the lu UP. 
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Figure 6: Frame quality classification in lu UP 



6.4.4.1.2 



Handling of FQC information in uplink path 



6.4.4.1.2.1 



Handling of FQC information at RNC 



In SRNC on the sending side, the Support Mode Functions takes as input the radio frame quality information together 
with the frame. Based on this, the FQC is set for the frame, a CRC is or is not added (depending on PDU type) and the 
frame is sent to CN. The following steps shall be sequentially applied to derive the SRNC behaviour and the FQC field 
setting: 

a) If there is at least one subflow with the "Delivery of erroneous SDUs" set to "No" and for at least one of those 
subflows the radio frame classification is "Bad" then the lu UP frame shall not be sent, 

b) Otherwise, if there is at least one subflow with the "Delivery of erroneous SDUs" set to "Yes" and for at least 
one of those subflows the radio frame classification is "Bad" then the lu UP frame shall be sent with FQC set 
to "Frame bad due to radio", 

c) Otherwise the lu UP frame shall be sent with FQC set to "frame good". 



6.4.4.1.2.2 



Handling of FQC information at ON 



The Support Mode Functions in CN on the receiving side makes a CRC check of the frame payload, if CRC is present 
and passes the appropriate frame and the appropriate frame quality classification information through the RNL-SAP. 
The following steps shall be sequentially applied to derive the CN behaviour and the FQC field setting: 

a) If a CRC is available and the CRC check indicates that the lu UP is "Bad" and at least one subflow has the "delivery 
of erroneous SDUs" set to "No", then the lu UP frame shall be dropped, 

b) Otherwise, if a CRC is available and the CRC check indicates that the lu UP is "Bad" and at least one subflow has 
the "delivery of erroneous SDUs" set to "Yes", then the lu UP frame shall be forwarded with the FQC set to "Bad", 

c) Otherwise the lu UP frame shall be forwarded with the FQC as set by UTRAN. 
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6.4.4.1 .3 Handling of FQC information in downlink path 

The Support Mode Functions in CN on the sending side adds a CRC, if necessary to the frame payload and passes it 
together with the FQC. If the payload stems from a transcoding unit of the NAS within the CN the FQC is always set to 
good. Otherwise it may be set by a partner peer entity residing in another RNC. 

The Support Mode Functions in SRNC then makes a CRC-check, if the CRC is present. Based on the CRC check, a 
decision is made whether to deliver the frame or not based on the following sequential steps: 

a) If a CRC is available and the CRC check indicates that the lu UP is "Bad" then the frame shall be drooped, 

b) Otherwise, if the FQC value of the lu UP frame is set to "frame bad" or "Frame bad due to radio", regardless of 
the CRC check indication. 

c) Otherwise, the frame shall be passed to radio interface protocols. 

NOTE: The case where SRNC receives a frame with the FQC set to "Frame bad due to radio" (respectively: 

"frame bad"), corresponds to a TrFO (respectively: TFO) case. The frame is then trashed by the receiving 
RNC since there is currently no means to pass the frame quality indicator down to the UE. 

6.5 Elementary procedures 

6.5.1 Transfer of User Data procedure 
6.5.1.1 Successful operation 

The purpose of the transfer of user data procedure is to transfer lu UP frames between the two lu UP protocol layers at 
both ends of the lu interface. Since an lu UP instance is associated to a RAB and a RAB only, the user data being 
transferred only relate to the associated RAB. 

The procedure is controlled at both ends of the lu UP instance i.e. SRNC and the CN. Exceptions in case of TrFO, 
where the partner peer entity does not reside within the serving CN node are described in subclause 4.1 and [13]. 

The transfer of user data procedure is invoked whenever user data for that particular RAB needs to be sent across the lu 
interface. 

The procedure is invoked by the lu UP upper layers upon reception of the upper layer PDU and associated control 
information: RFCI. 

The upper layers may deliver a frame quality classification information together with the RFCI. 

The NAS Data streams functions makes the padding of the payload (if needed) so that the lu UP frame payload will be 
an integer number of octets. Then the NAS Data streams functions perform, if needed, CRC calculation of the lu frame 
payload and passes the lu UP frame payload down to the frame handler together with the RFCI. 

The frame handler function retrieves the frame number from its internal memory, formats the frame header and frame 
payload into the appropriate PDU Type and sends the lu UP frame PDU to the lower layers for transfer across the lu 
interface. If the UTRAN initialises the RAB it shall base the selection of the PDU type (in both directions) on the 
reliability attributes (see [3]) for the RAB. If the reliability attribute 'Delivery of erroneous SDUs' equals 'no-error- 
detection-consideration' for all subflows then PDU type 1 shall be used, otherwise PDU type shall be used. 

For RABs with the traffic class conversational or streaming the frame number shall be based on time (stepped at each 
ITI). For RABs with another type of traffic class the frame numbering shall be based on sent lu UP PDU (stepped at 
each sent lu UP PDU). See description of Frame number. 

Upon reception of a user data frame, the lu UP protocol layer checks the consistency of the lu UP frame as follows: 
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The Frame handler checks the consistency of the frame header. If correct, the frame handler stores the frame 
number and passes the lu UP frame payload and associated CRC, if any to the NAS Data Streams functions. The 
received RFCI is passed to the Procedure Control Function; 

The NAS Data Streams functions check the payload CRC, if any. If the RFCI is correct (i.e. RFCI is used at 
Initialisation) and matches the lu UP frame payload (i.e. frame payload is not too short for the RFCI) as 
indicated by the Procedure Control functions, the NAS Data Streams removes the padding bits and the spare 
extension field when present from the lu UP frame payload based on the RFCI information. Then the NAS Data 
Streams forwards to the upper layers the RFCI and the payload. 
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Figure 7: Successful Transfers of User Data 



6.5.1.2 



Unsuccessful operation 



If the lu UP frame carrying the user data is incorrectly formatted or cannot be correctly treated by the receiving lu UP 
protocol layer, the lu UP protocol layer shall either discard the frame or pass it to the upper layers with a frame 
classification indicating a corrupted frame. This decision is based on configuration data of the lu UP instance for that 
particular RAB (i.e. if the RAB requests delivery of corrupted frame). 

If the lu UP protocol layer detects a frame loss because of a gap in the received frame number sequence while the frame 
number does not relate to time (see subclause Frame Number), the receiving lu UP protocol layer shall report this to the 
procedure control function. 
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Figure 8: Unsuccessful Transfers of User Data: 1) Corrupted Frame, 2) Detection of Frame loss 

6.5.2 Initialisation procedure 



6.5.2.1 



Successful operation 



This procedure is mandatory for RABs using the support mode for predefined SDU size. The purpose of the 
initialisation procedure is to configure both termination points of the lu UP with the RFCIs and associated RAB Sub 
Flows SDU sizes necessary during the transfer of user data phase. Additional parameters may also be passed, such as 
the Inter PDU Timing Interval (IPTI) information. 

The initialisation procedure may be controlled at both end of the lu access point, i.e. the CN and UTRAN. 

The initiahsation procedure is invoked whenever indicated by the lu UP Procedure Control function e.g. as a result of a 
relocation of SRNS or at RAB establishment over lu or if the CN decides to resolve RFCI mismatch in case of TrFO 
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(see [13]). The initialisation procedure shall not be re-invoked by the SRNC for the RAB without a RAB modification 
requested via RANAP [3]. 

When this procedure is invoked all other lu UP procedures are suspended until termination of the initialisation 
procedure. 

The lu UP protocol entity invoking this procedure indicates the lu UP Mode version it uses for the initialisation as well 
as the lu UP Mode versions it supports for the related RAB. The sender should use the lowest version for the 
initialisation that has enough information to initialise the highest proposed protocol version. 

The invoking entity allocates a RAB sub-Flow Combination indicator (RFCl) to each RAB sub-Flow Combination it 
initialises. The association of indicators to RAB Flow Combinations is valid for both the uplink and downlink direction 
in the lu UP until a new initialisation procedure is performed or the connection is terminated. 

The procedure control function may also generate additional lu UP protocol parameters necessary for the RAB service 
to operate properly over lu. 

To each RAB sub-Flow combination indicator is associated the size of each RAB sub-Flow SDU of that combination. 
The list of RAB sub-Flow Combination Indicators and their respective SDU sizes constitutes the RAB sub-Flow 
Combination set passed over the lu UP in the initialisation frame i.e. into an appropriate lu UP PDU Type. 

The first RAB sub-Flow Combination proposed in the list of RAB sub-Flow Combination indicates the initial RAB sub- 
Flow Combination i.e. the first RAB sub-Flow Combination to be used when starting the communication phase i.e. the 
transfer of user data procedure. 

The complete set of information is framed by the lu UP Frame Handler function and transferred in an lu UP 
initialisation frame. If needed, the initialisation frame CRC is calculated and set accordingly in the respective frame 
field. 

A supervision timer T iNixis started after sending the lu UP initialisation frame. This timer supervises the reception of 
the initialisation acknowledgement frame. 

Upon reception of a frame indicating that an initialisation control procedure is active in the peer lu UP entity, the lu UP 
protocol layer forwards the whole protocol information contained in the initialisation frame to the upper layers. It also 
stores the RAB sub-Flow Combination set (and thus replaces a possible previous set) in order to control during the 
transfer of user data, that the lu UP payload is correctly formatted (e.g. RFCl matches the expected lu UP frame 
payload total length). The peer lu UP entity receiving the initialisation message shall choose a version that it supports 
and for which it has enough initialisation information. 

If the initialisation frame is correctly formatted and treated by the receiving lu UP protocol layer, this latter sends an 
initialisation acknowledgement frame using the version of the lu UP Mode that is chosen. 

Upon reception of an initialisation acknowledgement frame, the lu UP protocol layer in the SRNC stops the supervision 
timer Tjnij. 

If the initialisation procedure requires that several frames are to be sent, each frame shall be acknowledged individually 
(i.e. any frame to be sent shall wait for the acknowledgement of the previous sent frame to be received before being 
sent. The supervision timer shall be used individually for each frame being sent. 

The successful operation of the initialisation procedure may require that one or several chained frames are positively 
acknowledged. The number of initialisation frames in such a chain shall not exceed 4. Each chained frame shall be 
positively acknowledged before the one with the next frame number can be sent. 

The frame number of an initialisation frame shall always be set to zero when the chain has only one frame. When 
several initialisation frames are used in a chain the frame number shall be set to zero for the first one and incremented 
by one in the sending direction for each new frame in the chain. The positive acknowledgement or negative 
acknowledgement shall carry the frame number of the frame being acknowledged. 

Upon reception of an initialisation negative acknowledgement frame, an erroneous acknowledgement or at timer T i^ix 
expiry, the lu UP protocol entity controlling the initialisation procedure shall reset and restart the T ]^yt supervision 
timer and repeat one initialisation frame with the same frame number. The repetition shall be performed up to N inix 
times, N ]^yt being chosen by the operator (default N i^ix = 3). The N i^ix (maximum number of allowed repetition) is 
the aggregate count for each frame in the chain and is restart each time a frame is positively acknowledged. 
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Consequently, when in the communication phase (as indicated by internal functions in the Radio Network layer), the 
frame transmission starts in downlink in the initial RFCI. 



RNC/ 
CN 



^ 



Initialisation 



CN/ 
RNC 



((RFCI, SDU sizes[, IPTIs^'])m) 



Initialisation ACK 



Transfer Of User Data 

* it can repeated n times 
^' optional 



6.5.2.2 



Figure 9: Successful Initialisation of lu UP for m RFCIs 



Unsuccessful operation 



If the initialisation frame is incorrectly formatted and cannot be correctly treated by the receiving lu UP protocol layer, 
this latter sends an initialisation negative acknowledgement frame. 

If the receiver does not support the lu UP Mode version for the initialisation procedure, it shall send a negative 
acknowledgement using the highest version it supports among the versions proposed by the sender. If none of the 
proposed versions are supported, the receiver shall respond with a negative acknowledgement using the highest version 
it supports. 

After N init successive negative acknowledgment, erroneous acknowledgment or T init expiry for initialisation frames 
having the same frame number, the initialisation procedure is unsuccessfully terminated and the lu UP protocol layers 
in RNC take appropriate local actions. 
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Figure 10: Unsuccessful initialisation of lu UP: 1) N init negative acknowledgement 

or 2) N INIT timer expires 

6.5.3 lu Rate Control procedure 



6.5.3.1 



Successful operation 



The purpose of the rate control procedure is to signal to the peer lu UP protocol layer the maximum rate over lu in the 
reverse direction of the sent rate control frame. 

The rate control procedure over lu UP is normally controlled by the entity controlling the rate control over UTRAN 
i.e. the SRNC. The lu rate control procedure is invoked whenever the SRNC decides that the maximum rate permitted 
downlink over lu shall be modified, or when a rate control command is received from the CN. Within the context of 
TrFO the SRNC may also receive rate control frames from the TrFO partner. 
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The rates that can be controlled by the SRNC are all the rates that are defined by the lu-Initialisation procedure and 
which are above the guaranteed bitrate (indicated to the lu UP at establishment) Rates below the guaranteed bitrate, e.g. 
the lowest speech rate or the SID frames, cannot be controlled (i.e. cannot be forbidden) by the SRNC. 

The procedure can be signalled at any time when transfer of user data is not suspended by another control procedure. 
When the user plane was initiated due to SRNS relocation reasons no rate control shall be signalled before the reception 
of the relocation execution trigger (see [3]). At the reception of the relocation execution trigger the RNC shall start the 
rate control procedure. This enables both TrFO partners to exchange current maximum rates and proceed user data 
transport based on latest rate decisions. Further, the reception of the first rate control frame from the target RNC, which 
indicates the CN the successful relocation execution on user plane level, should cause the CN to switch the user plane 
from the source RNC to the target RNC. 

The Procedure control function upon request of upper layer prepares the Rate control frame payload containing the 
maximum rate of the reverse direction of the rate control frame. To align the Rate Control procedure with version 1 of 
the lu UP protocol the permitted maximum rate is given as a set of RFCI indicators, that shall contain the maximum rate 
and all rates below the maximum rate, i.e. all rate controllable and non rate controllable rates. In the context of TrFO 
and TFO the Rate Control procedure may also be controlled by a remote peer. 

The frame handler function calculates the frame CRC, formats the frame header into the appropriate PDU Type and 
sends the lu UP frame PDU to the lower layers for transfer across the lu interface. 

A supervision timer Trc is started after sending the lu UP rate control frame. This timer supervises the reception of the 
rate control acknowledgement frame. Upon reception of a rate control acknowledgement frame, the lu UP protocol 
layer in the SRNC stops the supervision timer Trc- 

Upon reception of a rate control frame, the lu UP protocol layer checks the consistency of the lu UP frame as follows: 

The Frame handler checks the consistency of the frame header and associated CRC. If correct, the frame handler 
passes procedure control part to the procedure control functions; 

The procedure control functions check that the new permitted rate(s) are consistent with the RFCI set received at 
initialisation. They also verify that non-rate controllable rates are still permitted. If the whole rate control 
information is correct, the procedure control functions passes the rate control information to the NAS Data 
Streams specific functions; 

The NAS data streams specific functions forward to the upper layers the complete protocol data in a lu-UP- 
Status indication primitive; 

Upon reception of the lu-UP-Status request primitive, the procedure control functions shall acknowledge the 
Rate Control by including it's own maximum rate control information. 
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Figure 11 : Successful Rate Control 



6.5.3.2 



Unsuccessful operation 



If the lu UP protocol layer receives a rate control frame that is badly formatted or corrupted, it shall ignore the rate 
control frame, but sent a negative rate control acknowledgement frame back (Figure 13a). 
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Figure 13a: Negative Acknowledgement received from the peer 

If the lu UP in the SRNC detects that the rate control command has not been correctly interpreted or received (e.g. the 
observed rate is outside the set of permitted rates in the reverse direction of the rate control frame (Figure 13b), or a 
NACK message has been received, or no ACK message was received before the supervision timer Trc expires (Figure 
13c)), the lu UP shall retrigger a rate control procedure. If after N rc repetitions, the error situation persists, the lu UP 
protocol layers (sending and receiving) take the appropriate local actions. 
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Figure 13: Unsuccessful Transfer of rate control from RNC: 1) Frame loss 2) Corrupted Frame 
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Figure 13b: Unsuccessful Transfer of rate control: undetected error 
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Figure 13c: Unsuccessful Transfer of rate control: lost rate control 

6.5.3.2A Frequent Rate Control Procedures 

Typically a new rate control command should not be sent in the same direction before the previous rate control 
procedure was terminated successfully. 

If for some reasons (e.g. frequently received rate control commands from the CN in a TFO connection to GSM) a rate 
control command has to be sent before the previous rate control procedure was terminated successfully, then the 
previous rate control procedure is defined as terminated successfully: the supervision timer Trc shall be stopped and 
acknowledgement frames (positive or negative) for the previous rate command shall be ignored, i.e. only the most 
recent rate control procedure shall be active in the same direction. 
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Figure 14: Frequent Rate Control: only most recent one is important 



6.5.4 Time Alignment procedure 



6.5.4.1 



Successful operation 



The purpose of the time alignment procedure is to minimise the buffer delay in RNC by controlling the downlink 
transmission timing in the peer lu UP protocol layer entity. 

The time alignment procedure is controlled by SRNC. 

The time alignment procedure is invoked whenever the SRNC detects the reception of lu UP PDU at an inappropriate 
timing that leads to an unnecessary buffer delay. The actual detection of the trigger in SRNC is an internal SRNC matter 
and is out of the scope of the present document. 
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The lu UP protocol layer entity in SRNC indicates the peer entity the necessary amount of the delay or advance 
adjustment in the number of 500 [is steps. 

A supervision timer Tta is started after sending the lu UP time alignment frame. This timer supervises the reception of 
the time alignment acknowledgement frame. 

The requested lu UP protocol layer entity in the peer node adjusts the transmission timing by the amount as indicated by 
SRNC. 

If the time alignment frame is correctly formatted and treated by the receiving lu UP protocol layer and the time 
alignment is treated correctly by the upper layers, this latter sends an time alignment acknowledgement frame. 

Upon reception of a time alignment acknowledgement frame, the lu UP protocol layer in the SRNC stops the 
supervision timer Tta- 

The procedure can be signalled at any time when transfer of user data is not suspended by another control procedure. 
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Figure 15a: Successful Time Alignment 



6.5.4.2 



Unsuccessful operation 



If the Time Alignment could not be handled by the peer side, the peer side should send a NACK with a corresponding 
cause. When the lu UP in the SRNC receives a NACK with cause "Time Alignment not supported", then the SRNC 
shall not send additional Time Alignment frames for that RAB (unless the lu UP conditions change for that RAB). The 
cause value "Requested Time Alignment not possible" is used to indicate that the requested time alignment was not 
possible at that moment. At a later moment the SRNC may initiate a new Time Alignment command when needed. If 
the Time Alignment is received by the RNC, it shall respond with a NACK with the cause "Time Alignment not 
supported". 

If the lu UP in the SRNC detects that the time alignment command has not been correctly interpreted or received, 
i.e NACK received or timer expires, and the time alignment need still persists, the lu UP should retrigger a time 
alignment procedure. If after N ta repetitions, the error situation persists, the lu UP protocol layers take appropriate 
local actions. 

Upon reception of a time alignment negative acknowledgement frame, the lu UP protocol layer in the SRNC stops the 
supervision timer Tta- 
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Figure 16a: Unsuccessful Time Alignment: 1) N ta negative acknowledgements 

or 2) N TA timer expiries 
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Figure 16b: Time Alignment received by the RNC 



6.5.5 Handling of Error Event procedure 



6.5.5.1 



Successful operation 



The purpose of the Error event procedure is to handle the error reporting. Over the lu UP protocol the error reports are 
made with Error event frames. The Error event procedure in the lu UP can be triggered by: 

An error detected by the lu UP functions (by receiving an erroneous frame or by receiving a frame with 
unknown or unexpected data). In this case an lu UP- Status Indication may be used to inform the upper layers; 

A request by the upper layers. 

When an Error event is reported by an Error event frame the following information shall be included: 

A cause value; 

Error distance (=0 if lu UP function detected, =1 if requested by upper layers). 

Upon reception of an Error report frame the lu UP functions should take appropriate local actions based on the cause 
value. This may include reporting the error to the upper layers with an lu UP status indication. 



RNC/ 
CN 



CN/ 
RNC 



Error event 
(Cause value, 
Error distance) 



Figure 15b: Successful Error event 
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6.5.5.2 



Unsuccessful operation 



If the error event frame is incorrectly formatted and cannot be correctly treated by the receiving lu UP protocol layer 
appropriate local actions are taken (e.g. upper layers are informed). An error in an Error event frame should not 
generate the sending of a new Error event frame. 



RNC/ 
CN 



Error event (Cause, 
Error distance) 



CN/ 
RNC 



M 



Error event (Cause, 
Error distance) /l/\» 



1) 



2) 



Figure 16c: Unsuccessful Transfer of Error event frame: 1) Frame loss 2) Corrupted Frame 

6.5.6 Frame Quality Classification 

The Frame Quality Classification procedure uses the services of the Transfer of User Data procedure to exchange across 
the lu UP interface the Frame Quality Classification information. 



TOSO 



CN/ 



CN Transfer of User Data RNC 
(FQC, RFCI, payload) 



Transfer of User Data 
(FQC, RFCI, payload) 



Figure 17: Successful Transfers of User Data with FQC information 

6.6 Elements for lu UP communication in Support mode 
6.6.1 General 

In the present document the structure of frames will be specified by using figures similar to Figure 18. 
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Bits 


-z. 

CO -> 
o 






7 


6 


5 


4 


3 


2 


1 







Field 1 


Field 2 


1 


Octet 1 


Header 
part 


Field 3 


Field 4 


2 


Octet 2 
Octet 3 


Field 4 continue 


Spare 


Field 6 


2 


Octet 4 
Octet 5 


Payload 
part 


Field 6 continue 


Padding 


Spare extension 


0-m 





Figure 18: Example frame format 

Unless otherwise indicated, fields which consist of multiple bits within an octet will have the more significant bit 
located at the higher bit position (indicated above frame in figure 18). In addition, if a field spans several octets, more 
significant bits will be located in lower numbered octets (right of frame in figure 18). 

On the lu interface, the frame will be transmitted starting from the lowest numbered octet. Within each octet, the bits 
are sent according decreasing bit position (bit position 7 first). 

Spare bits should be set to by the sender and should not be checked by the receiver. 

The header part of the frame is always an integer number of octets. The payload part is octet rounded (by adding 
'Padding' when needed). 

The receiver should be able to remove an additional spare extension field that may be present at the end of a frame. See 
description of Spare extension field. 

6.6.2 Frame Format for predefined size SDUs 



6.6.2.1 



PDU Type 



PDU Type is defined to transfer user data over the lu UP in support mode for pre-defined SDU sizes. Error detection 
scheme is provided over the lu UP for the payload part. 

The following shows the lu frame structure for PDU type of the lu UP protocol at the SAP towards the transport 
layers (TNL-SAP). 
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Bits 


-z. 




7 


6 


5 


4 


3 


2 


1 









PDU Type (=0) 


Frame Number 


1 


Frame 
Control 
Part 


FQC 


RFCI 


1 


Header CRC 


Payload CRC 


2 


Frame 
Check 
Sum Part 


Payload CRC 


Payload Fields 


0-n 


Frame 

Payload 

part 


Payload Fields 


Padding 


Spare extension 


0-4 



Figure 19: lu UP PDU Type Format 

The lu UP PDU Type is made of three parts: 

1) lu UP Frame Control part (fixed size); 

2) lu UP Frame Check Sum part (fixed size); 

3) lu UP Frame Payload part (pre-defined SDU sizes rounded up to octets [Note: this does not consider the usage of 
spare extension field]). 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type Frame Header. 

6.6.2.2 PDU Type 1 

PDU Type 1 is defined to transfer user data over the lu UP in support mode for pre-defined SDU sizes when no payload 
error detection scheme is necessary over lu UP (i.e. no payload CRC). 

The following shows the lu frame structure for PDU type 1 of the lu UP protocol at the SAP towards the transport 
layers (TNL-SAP). 
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Bits 


-z. 




7 


6 


5 


4 


3 


2 


1 









PDUType(=1) 


Frame Number 


1 


Frame 
Control 
Part 


FQC 


RFCI 


1 


Header CRC 


Spare 


1 


Frame 
Check 
Sum Part 


Payload Fields 


0-n 


Frame 

Payload 

part 


Payload Fields 


Padding 


Spare extension 


0-4 



Figure 20: lu UP PDU Type 1 Format 

The lu UP PDU Type 1 is made of three parts: 

1) lu UP Frame Control part (fixed size); 

2) lu UP Frame Check Sum part (fixed size); 

3) lu UP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note: this does not consider the usage 
of spare extension field]). 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 1 Frame Header. 



6.6.2.3 



PDU Type 14 



6.6.2.3.1 



General 



PDU Type 14 is defined to perform control procedures over the lu UP in support mode for pre-defined SDU sizes. The 
control procedure is identified by the procedure indicator. The Frame Payload contains the data information related to 
the control procedure. 

Figure 21 below shows the lu frame structure for PDU Type 14 of the lu UP protocol at the SAP towards the transport 
layers (TNL-SAP). 
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Bits 


-z. 

CO -^ 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack (=0, 
i.e. procedure) 


PDUType 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 


1 


Header CRC 


Payload CRC 


1 


Frame 
Checksu 
m Part 


Payload CRC 


1 


Reserved for procedure data 


0-n 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 21 : lu UP PDU Type 14 Format for procedure sending 

The lu UP PDU Type 14 is made of three parts: 

1) lu UP Frame Control part (fixed size); 

2) lu UP Frame Check Sum part (fixed size); 

3) lu UP Frame Payload part (variable length, rounded up to octet). 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 14 Frame Header. 

6.6.2.3.2 Positive Acknowledgement 

When the PDU Type 14 is used to positively acknowledge a control procedure, the PDU Type 14 frame takes the 
following structure at the TNL-SAP. 
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Bits 


-z. 

CO -^ 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack (=1 , 
i.e. Ack) 


PDUType 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 

(indicating the procedure being 
positively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 


Spare extension 


0-32 


Frame 

Payload 

part 



Figure 22: lu UP PDU Type 14 Format for positive acknowledgement 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 14 Frame Header for 
positive acknowledgement. 



6.6.2.3.3 



Negative Acknowledgement 



When the PDU Type 14 is used to negatively acknowledge a control procedure, the PDU Type 14 frame takes the 
following structure at the TNL-SAP. 



Bits 


"1 

CO -■ 




7 


6 


5 


4 


3 


2 


1 







PDU Type (=14) 


Ack/Nack (=2, 
i.e. Mack) 


PDUType 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 

(indicating the procedure being 
negatively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 


Error Cause value 


Spare 


1 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 23: lu UP PDU Type 14 Format for negative acknowledgement 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 14 Frame Header for 
negative acknowledgement. 
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6.6.2.3.4 



Procedures Coding 



6.6.2.3.4.1 Initialisation 

Figure 24 specifies how the initialisation procedure frame is coded. 



Bits 


-z. 
G S- 

CO -^ 

o 




7 


6 


5 


4 


3 


2 


1 









PDU Type (=14) 


Ack/Nack (=0. 
I.e. Procedure) 


PDU Type 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=0) 


1 


Header CRC 


Payload CRC 


2 


Frame 

Checksum 

part 


Payload CRC 


Spare 


Tl 


Number of subflows per 
RFCI (N) 


Chain 
Ind 


1 


Frame 

payload 

part 


LRI 


LI 


1''RFCI 


1 


Length of subflow 1 


1 or 2 
(dep. LI) 


Length of subflow 2 to N 


(N-I)x(l 
or 2) 


LRI 


LI 


2"" RFCI 


1 


Length of subflow 1 


1 or 2 

(dep. LI) 


Length of subflow 2 to N 


(N-I)x(l 
or 2) 






IPTIof 1"RFCI 


IPTIof2"''RFCI 


or M/2 

(M: 
Number 
of RFCIs 
in frame) 


IPTIofS'^'RFCI 




lu UP Mode Versions supported (bitmap) 


2 


Data PDU type 


Spare 


1 


Spare extension 


0-32 



Figure 24: lu UP PDU Type 14 used for Initialisation 
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6.6.2.3.4.2 



Rate Control 



6.6.2.3.4.2.1 Rate Control procedure 

Figure 25 specifies how the rate control procedure frame is coded. 



Bits 


"1 
o 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack (=0, 
I.e. Procedure) 


PDUType14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=1) 


1 


Header CRC 


Payload CRC 


1 


Frame 
Checksu 

m Part 


Payload CRC 


1 




Spare 


Number of RFCI Indicators (M) 


1 


Frame 

payload 

part 


RFCIO 
Ind. 


RFCI 1 
Ind 




RFCI 
M-1 
Ind 


Padding 


0-n 


Spare extension 


0-32 





Figure 25: lu UP PDU Type 14 Format used for Rate Control 

6.6.2.3.4.2.2 Rate Control positive acknowledgement 

Figure 25a specifies how the rate control positive acknowledgement frame is coded. 
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Bits 


"1 
o 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


AGl</Nacl<(=1, 
i.e. Ack) 


PDUType14 
Frame Number 


1 


Frame 

Control 

Part 


lu UP Mode version 


Procedure Indicator 

(indicating the procedure being 
positively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 


Spare 


Number of RFCI Indicators (IVI) 


1 


Frame 

Payload 

part 


RFCIO 
Ind. 


RFCI 1 
Ind 




RFCI 
M-1 
Ind 


Padding 


0-n 


Spare extension 


0- 

(31 -n) 



Figure 25a: lu UP PDU Type 14 Format for positive acknowledgement 

6.6.2.3.4.3 Time Alignment 

Figure 26 specifies how the time alignment procedure is coded. 
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Bits 


-z. 

CO -^ 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack(=0) 


PDUType 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=2) 


1 


Header CRC 


Payload CRC 


1 
1 


Frame 
Checksu 
m Part 


Payload CRC 


Time alignment 


1 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 26: lu UP PDU Type 14 Format used for Time Alignment 



6.6.2.3.4.4 Error Event 

Figure 27 specifies how the Error Event procedure is coded. 



Bits 


"1 

CO -^ 




7 


6 


5 


4 


3 


2 


1 







PDU Type (=14) 


Ack/Nack(=0) 


PDUType 14 
Frame Number 


1 


Frame 

Control 

Part 


lu UP IVIode version 


Procedure Indicator (=3) 


1 


Header CRC 


Payload CRC 


1 
1 


Frame 
Checksu 
m Part 


Payload CRC 


Error distance 


Error Cause value 


1 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 27: lu UP PDU Type 14 Format used for Error Event 



6.6.3 Coding of information elements in frames 



6.6.3.1 



PDU Type 



Description: The PDU type indicates the structure of the lu UP frame. The field takes the value of the PDU Type it 
identifies: i.e. for PDU Type 0. The PDU type is in bit 4 to bit 7 in the first octet of the frame. PDU type is used in all 
frames in support mode for predefined SDU sizes version 1 . 

Value range: {0-1 and 14 in use, 2-13: reserved for future PDU types, 15=reserved for future PDU type extensions} 

Field length: 4 bits 
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6.6.3.2 Ack/Nack 

Description: The Ack/Nack field tells if the frame is: 

A control procedure frame; 

A positive acknowledgement (ACK) of a control procedure frame; 

A negative acknowledgement (NACK) of a control procedure frame. 
Value range: {O=control procedure frame, 1=ACK, 2=NACK, 3=reserved} 
Field length: 2 bits 

6.6.3.3 Frame Number 

Description: The lu UP frame numbering is handled by a Frame Number. The frame numbering can be based on either 
time or sent lu UP PDU. In case the frame numbering is based on time the purpose of the frame number is to be of help 
in handling the Time Alignment functionality. When the frame number is based on time, the Frame number is 
incremented by one (modulo 16) at each new ITI. In case the Frame number relates to sent lu UP PDU the purpose of 
the Frame Number is to provide the receiving entity with a mechanism to keep track of lost lu UP frames. When the 
frame number is based on sent lu UP PDU, the Frame number is incremented by one (modulo 16) for each sent lu UP 
PDU. For a given user data connection, there is no relations between the frame numbers of frames sent in the downlink 
direction and the frame numbers of frames sent in the uplink direction. 

In the case the Frame Number relates to sent lu UP PDU, the following applies: 

Frame loss is when an incoming PDU frame has a frame number that is equal to (previous PDU frame number + 2) 
modulo [max. PDU frame number + 1 ] . This indicates that one and only one PDU frame has been lost. 

Unexpected frame number is when an incoming PDU does not have the expected frame number and is not 
considered as a Frame Loss. 

Value range: {0-15}. 

Field length: 4 bits. 

6.6.3.4 PDU Type 14 Frame Number 

Description: The lu UP frame numbering is handled by a Frame Number. The purpose of the PDU Type 14 Frame 
Number is to provide the receiving entity with a mechanism to keep track of lost lu UP frames. It is also used to relate 
the acknowledgment frame to the frame being acknowledged i.e. the same PDU Type 14 Frame Number is used in the 
acknowledgement frame as the one used in the frame being acknowledged. 

Value range: {0-3}. 

Field length: 2 bits. 

6.6.3.5 Frame Quality Classification (FQC) 

Description: Frame Quality Classification is used to classify the lu UP frames depending on whether errors have 
occurred in the frame or not. Frame Quality Classification is dependent on the RAB attribute 'Delivery of erroneous 
SDUs'. 

Value range: {0=frame good, l=frame bad, 2=Frame bad due to radio, 3=spare}. 

Field length: 2 bits. 

6.6.3.6 RAB sub-Flow Combination Indicator (RFCI) 

Description: The RPCI identifies the structure of the payload. This can be used to specify the sizes of the subflows. 
Value range: {0-62, 63=RFCI not applicable}. 
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Field length: 6 bits. 

6.6.3.7 Procedure Indicator 

Description: The Procedure Indicator identifies the control procedure in the current frame. 
Value range: {O=initialization, l=rate control, 2=time alignment, 3=error event, 4-15=reserved}. 
Field length: 4 bits. 

6.6.3.8 Header CRC 

Description: This field contains the CRC of all fields in Frame Control Part. The CRC is a 6-bit checksum based on the 
generator polynom G(D) = DVD^+D^+D^+D'+1, see subclause 6.7.7. With this CRC all error bursts shorter than 7 bits 
are detected, as well as all odd number of bits faulty (and two-bit faults) when the protected area is shorter than 24 bits, 
(max 3 octets). 

Field length: 6 bits. 

6.6.3.9 Payload CRC 

Description: This field contains the CRC of all the fields (including Padding and possible Spare extension) of the 
Frame Payload Part. The CRC is a 10 bit checksum based on the generator polynom G(D) = D'^h- D^h-D^h-D''h-D'h-1, see 
subclause 6.7.7. With this CRC all error bursts shorter than 1 1 bits are detected, as well as all odd number of bits faulty 
(and two-bit faults) when the protected area is shorter than 500 bits (max 62 octets). 

Field length: 10 bits. 

6.6.3.10 Chain Indicator 

Description: Chain indicator is used to indicate whether the control procedure frame is the last frame related to the 
control procedure. 

Value range: {0=this frame is the last frame for the procedure, l=additional frames will be sent for the procedure}. 

Field length: 1 bit. 

6.6.3.1 1 Number of Subflows per RFCI 

Description: Number of Subflows per RFCI field indicates the number of subflows the RAB is made of. It is used to 
decode the SDU size information data lengths. All RFCs consist of the same number of subflows within a specific 
RAB. 

Value range: {0=reserved, 1-7}. 

Field length: 3 bits. 

6.6.3.12 Length Indicator (LI) 

Description: Length Indicator, indicates if 1 or 2 octets is used for the RAB subflow size information. 
Value range: {O=one octet used, l=two octets used}. 
Field length: 1 bit. 

6.6.3.13 Number of RFCI Indicators 

Description: Number of RFCI indicators indicates the number of RFCI indicators present in the control procedure 
frame. 

Value range: {0-63}. 
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Field length: 6 bits. 

6.6.3.14 RFCI n Indicator 

Description: RFCI n Indicator points to an RFCI number e.g. RFCI Indicator points to RFCI 0, RFCI 1 Indicator 
points to RFCI 1 , etc . . . 

Value range: {0=RFCI allowed, 1=RFCI barred}. 

Field length: 1 bit. 

6.6.3.15 Error distance 

Description: Indicates if the error occurred at the error reporting entity (=0) or in a more distant entity. The error 
distance is incremented by one (or kept at its maximum value) when an error report is forwarded. 

0: Reporting local error 
1 : First forwarding of error event report 
2: Second forwarding of error event report 
3: Reserved for future use 

Value range: {0: Reporting local error, 1: First forwarding of error event report. 2: Second forwarding of error event, 3: 
Reserved for future use } . 

Field length: 2 bit. 

6.6.3.1 6 Error Cause value 

Description: Cause value is used to indicate what kind of error caused the error. Error cause value is used in N ACK 
and Error Event frames. 

0: CRC error of frame header 

1 : CRC error of frame payload 

2: Unexpected frame number 

3: Frame loss 

4: PDU type unknown 

5: Unknown procedure 

6: Unknown reserved value 

7: Unknown field 

8: Frame too short 

9: Missing fields 

10-15: spare 

16: Unexpected PDU type 

17: spare 

18: Unexpected procedure 

19: Unexpected RFCI 

20: Unexpected value 

21^1: spare 

42: Initialisation failure 

43: Initialisation failure (network error, timer expiry) 

44: Initialisation failure (lu UP function error, repeated NACK) 

45: Rate control failure 

46: Error event failure 

47: Time Alignment not supported 

48: Requested Time Alignment not possible 

49: lu UP Mode version not supported 

50-63: spare 

Value range: {0-15 Used for syntactical protocol errors, 16^1 Used for semantical protocol errors, 42-63 Used for 
other errors } . 

Field length: 6 bit. 
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6.6.3.17 Padding 

Description: This field is an additional field used to make the frame payload part an integer number of octets when 
needed. Padding is set to by the sender and is not interpreted by the receiver. 

Value range: {0-127}. 

Field length: 0-7 bits. 

6.6.3.18 Time alignment 

Description: Time alignment indicates the amount the sending time should be advanced or delayed. 

0: Reserved 

1: Delay l*500)is 

80: Delay 80*500)is 
81-127 Reserved 
128: Reserved 
129: Advance l*500)is 

208: Advance 80*500)is 
209-255 Reserved 

Value range: {0: Reserved, 1-80: used for delay, 81-128: Reserved, 129-208 used for advance, 209-255: Reserved}. 

Field length: 8 bit. 

6.6.3.19 Spare 

Description: The spare field is set to by the sender and should not be interpreted by the receiver. 
Value range: (0-2"-l). 
Field Length: n bits. 

6.6.3.20 Spare extension 

Description: The spare extension field shall not be sent. The receiver should be capable of receiving a spare extension. 
The spare extension should not be interpreted by the receiver. This since in later versions of the present document 
additional new fields might be added in place of the spare extension. The spare extension can be an integer number of 
octets carrying new fields or additional information; the maximum length of the spare extension field (m) depends on 
the PDU type. 

Value range: 0-2"***-l. 

Field Length: 0-m octets. For PDU Types in the set {0,1 }, m=4. For PDU Types in the set {14}, m=32. 

6.6.3.21 LRI, Last RFC! Indicator 

Description: The Last RFCl Indicator is used to indicate which is the last RFCI in the current Initialisation frame. This 
makes it possible for a receiver to detect a spare extension field. 

Value range: (0: Not last RFCI, 1: Last RFCI in current frame). 

Field Length: 1 bit. 

6.6.3.22 Length of subflow 

Description: This field indicates the length of the corresponding subflow as number of bits per SDU. 
Value range: (0-255 if LI=0, 0-65535 if LI=1). 
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Field Length: 8 or 16 bits (depending on LI). 

6.6.3.23 Tl 

Description: This field indicates if Timing Information is included in the Initialisation frame. 
Value range: {0: IPTls not present, 1: IPTls present in frame}. 
Field length: 1 bit. 

6.6.3.24 IPTI of n'*^ RFCI 

Description: This field indicates the IPTl value in number of ITls for the corresponding RFCI (in the same order as the 
RFCls occur in the Initialisation frame). 

Value range: {0-15}. 

Field length: 4 bits. 

6.6.3.25 lu UP Mode versions supported 

Description: This field indicates the lu UP Mode Versions supported by the RNC for the related RAB. Up to 16 lu UP 
Mode versions can be simultaneously available. 

Value range: 

Each bit, in the two octet field, indicates a lu UP Protocol version: (First octet, bit 7) indicates version 16, (Second 
octet, bit 0) indicates version 1 . 

Bit = means "Version not supported" 

Bit = 1 means "Version supported" 

Field length: 2 octets 

6.6.3.26 lu UP Mode Version 

Description: This field indicates the lu UP Mode version. Up to 16 lu UP Mode Versions can be simultaneously 
available. 

Value range: { 1-16} The binary coded value is the version number minus 1 (e.g. version 1 is coded '0000', ..., version 
16 is coded '1111'). 

Field length: 4 bits 

6.6.3.27 Payload fields 

Description: This field contains the Subflow SDUs, starting with the Subflow 1 SDU. The MSB of the Subflow 1 SDU 
is placed in bit 7 of the first octet (see example in Figure 27a below). 

Value range: {any value}. 

Field length: Sum of the lengths of the included Subflow SDUs. 
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Bits 


9, ^ 

gl 

CD CD 
CO "■ 


7 


6 


5 


4 


3 


2 


1 





Subflow 1 SDU 


1 


Subflow 1 SDU cont. 


Subflow 2 SDU 


1 


Subflow 2 SDU cont. 


Padding 

(Not part of 

'Payload fields') 


1 



Figure 27a: Example of 'Payload fields' with two Subflow SDUs 

6.6.3.28 Data PDU type 

Description: This field indicates the PDU type that shall be used (in both directions) for transferring user data. 
Value range: {0: PDU type 0, 1: PDU type 1, 2-15: Reserved for future use}. 
Field length: 4 bits. 

6.6.4 Timers 



This Timer is used to supervise the reception of the initialisation acknowledgement frame from the peer lu UP instance. 
This Timer is set by O&M. 



This Timer is used to supervise the reception of the time alignment acknowledgement frame from the peer lu UP 
instance. This Timer is set by O&M. 



This Timer is used to supervise the reception of the rate control frame from the peer lu UP instance. This Timer is set 
by O&M. 

6.6.5 Maximum values of repetition counters 

NiNIT 

Maximum number of repetitions of an Initialisation frame due to failure at the Initialisation procedure. 

Nrc 

Maximum number of repetitions of a Rate Control frame due to failure at the Rate Control procedure. 

Nta 

Maximum number of repetitions of a Time Alignment frame due to failure at the Time Alignment procedure. 

6.7 Handling of unknown, unforeseen and erroneous protocol 
data 

6.7.1 General 

Error handUng in lu UP protocol is applicable only for lu UP in Support mode. 
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The Error Event procedure is the procedure handling error reporting. The Error event procedure in the lu UP can be 
triggered by: 

An error detected by the lu UP functions (by receiving an erroneous frame or by receiving a frame with 
unknown or unexpected data); 

A request by the upper layers; 

Sn Error event frame over the lu UP protocol. 

The error can be reported either by: 

An Error event frame over the lu UP protocol; 

An lu UP Status Indication to upper layers (e.g. to be used by O&M). 

When an Error event is reported, either by an lu-UP-Status-Indication, or by an Error event frame the following 
information shall be included: 

Type of the error (syntactical error, semantical error or other error); 

Error distance, i.e. information where the error occurred. 

6.7.2 Error detected by lu UP functions 

When an error is detected within the lu UP functions (by receiving a frame containing erroneous, unknown or 
unexpected data) one of the following actions is taken depending on the type of the error: 

1. Error indicated to upper layers by sending a lu-UP-Status-Indication primitive; 

2. Error event frame sent; 

3. Error event frame sent and error indicated to upper layers by sending a lu-UP-Status-Indication primitive; 

4. No action. 

6.7.3 Request by upper layers 

When the lU UP receives an lu-UP-Status-Request indicating Error event then an Error event frame should be sent over 
the lu UP protocol indicating the appropriate error type. 

6.7.4 Error event frame over the lu UP protocol 

When an Error event frame is received over the lu UP protocol an lu-Status-Indication with 'Error event' information 
indicating the error type should be made to the upper layers. The Error event report contains a 'Cause value' that tells the 
type of the error. The Error event report also contains a field 'Error distance' that tells the distance to the entity reporting 
the error event. The 'Error distance' is when the error is originally sent. When an Error event report is forwarded the 
'Error distance' is incremented by one. 

6.7.5 Handling of error reports 
6.7.5.1 General 

Figure 28 shows the external error case when the error event procedure is originally triggered by an lu-UP-Status- 
Request. As an action on this the error event procedure sends an error event frame over the lu UP. On the other side the 
reception of error event frame triggers the error event procedure, and an lu-UP-Status-Indication is sent to upper layers. 
The handling is symmetrical over the lu UP protocol. 
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Figure 28: External error 

Figure 29 shows the internal error case when the error event procedure is originally triggered by the lu UP functions. As 
an action on this the error event procedure sends an error event frame over the lu UP. On the other side the reception of 
error event frame triggers the error event procedure, and an lu-UP-Status-Indication is sent to the upper layers. The 
handling is symmetrical over the lu UP protocol. 
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Figure 29: Internal error 
6.7.5.2 Error distance 

In an error event frame the error distance has the following meaning: 

0: Error report relates to an lu UP function error at the other side 

1 : Error report relates to an error at the other side reported by the upper layers 

In an lu UP-Status indication the error distance has the following meaning: 

0: Error report relates to an local lu UP function error 

1 : Error report relates to an lu UP function error at the other side 

2: Error report relates to an error at the other side reported by the upper layers 
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6.7.6 List of errors in lu UP 



Table 4: List of errors in lu UP 



Error Type 


Error Cause 


Recommended action 

by Error event 

procedure 


Possibly 

detected by 

function 


Comment 


Syntactical 


CRC error of Frame 


No action 


NAS data streams 


Handled by 




payload (CRC check) 




functions 


Frame Quality 
Classification, 
when applied 


CRC error of Frame 


lu-UP-Status- 


Frame handler 


Frame 




Header (CRC check) 


lndication(Error event) 


functions 


discarded 


Unexpected Frame 


lu-UP-Status- 


NAS data streams 


See 6.6.3.3 




Number 


lndication(Error event) 


functions 




Frame loss 


lu-UP-Status- 


NAS data streams 


See 6.6.3.3 






lndication(Error event) 


functions 








and Error event frame 






PDU type Unknown 


lu-UP-Status- 


Frame handler 


Used when 






lndication(Error event) 


functions 


PDU type is 






and Error event frame 




notO, 1, or 14 


Unknown procedure 


lu-UP-Status- 


Frame handler 


Used when 






lndication(Error event) 


functions 


procedure 






and Error event frame 




value is 
neither 0, 1, 2, 
or 3 


Unknown reserved value 


See 8.1.1 






Unknown field 






This error 










cause shall not 










be sent. 


Frame too short 


lu-UP-Status- 


Frame handler 


Used when: 






lndication(Error event) 


functions 


- the length of 






and Error event frame 




the entire 
received PDU 
is less than 
the expected 
(calculated) 
PDU header 
length, or 
- the length of 
the payload 
(entire 

received PDU 
minus PDU 
header length) 
is less than the 
expected 
(calculated) 
payload length 


Missing fields 


lu-UP-Status- 


Frame handler 


This error 






lndication(Error event) 


functions 


cause shall not 






and Error event frame 




be sent. 


Semantical 


Unexpected PDU type 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Unexpected procedure 


lu-UP-Status- 


Frame handler 








lndication(Error event) 


functions 








and Error event frame 






Unexpected RFC! 


lu-UP-Status- 


NAS data streams 








lndication(Error event) 


functions 








and Error event frame 






Unexpected value 


lu-UP-Status- 


Procedure control 








lndication(Error event) 


functions 








and Error event frame 






Other error 


Initialisation failure 
(outside lu UP) 


Error event frame 


Function outside 
luUP 





£75/ 



3GPP TS 25.415 version 4.1.0 Release 4 



46 



ETSI TS 125 415 V4.1.0 (2001-06) 



Error Type 


Error Cause 


Recommended action 

by Error event 

procedure 


Possibly 

detected by 

function 


Comment 




Initialisation failure 
(network error, timer 
expiry) 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Initialisation failure (lu UP 
function error, repeated 
NACK) 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Rate control failure 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Error event failure 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Time Alignment not 
supported 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Requested Time 
Alignment not possible 


lu-UP-Status- 
lndication(Error event) 


Function outside 
luUP 




lu UP version not 
supported 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 





6.7.7 Error detection 



6.7.7.1 



General 



Error detection is provided on frames through a Cyclic Redundancy Check. The CRC for the payload is 10 bits and for 
the header it is 6 bits. 

6.7.7.2 CRC Calculation 

The parity bits are generated by one of the following cyclic generator polynomials: 
gcRC6(D) = D^ + D^ + DV D^ + D' + 1; 

gcRCio(D) = D"' + D% D' + D* + D' + 1. 

Denote the bits to be protected of a frame by a^,a2,ClT,,...,ClA{Cl^ being the bit with the highest bit position in the 

first octet), and the parity bits by p^, P2, p^,---. Pi ■ A, is the length of the protected data and L, is 6 or 10 depending 
on the CRC length. 

The encoding is performed in a systematic form, which means that in GF(2), the polynomial 
UiD^'^^ +a2D^^^* +... + a^D^ + p^D^ + p^D'* +...+ p^D^ + p^ 
yields a remainder equal to when divided by gcRC6(D) and the polynomial 



,A.+9 



.A; +8 



a.D'"'^'' +a2D'''^'' +... + a^D''' + p^D^ + p^D^ +...+ PgD' + /?,„ 

yields a remainder equal to when divided by gcRcio(D). If A^ = , Py = P2— Pj,—'" — Pl ~ ^ ■ 



6.7.7.3 



Relation between input and output of the Cyclic Redundancy Check 



The protected bits are left unchanged in the frame. The parity bits for the Header CRC are put in the Header CRC field 
with Pj being the highest bit position of the first octet of the Header CRC field. The parity bits for the Payload CRC are 
put in the Payload CRC field with p^ being the highest bit position of the first octet of the Payload CRC field. 
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7 Communication Primitives for the lu UP protocol 

layer 

7.1 Modelling Principle 

The principle illustrated by figure 30 is used for modelling the primitives towards the protocol layer. 

REQUEST 




Figure 30: Modelling principle 



7.2 Primitives towards the upper layers at the RNL SAP 



7.2.1 



General 



The lu UP protocol layer interacts with upper layers as illustrated in the figure above. The interactions with the upper 
layers are shown in terms of primitives where the primitives represent the logical exchange of information and control 
between the upper layer and the lu UP protocol layer. They do not specify or constrain implementations. 

The following primitives are defined: 

- lu-UP-DATA; 

- lu-UP-STATUS; 

- lu-UP-UNIT-DATA. 
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Table 1 : lu UP protocol layer service primitives towards the upper layer at the RNL SAP 



Primitive 


Type 


Parameters 


Comments 


lu-UP-DATA 


Request 


lu-UP-payload 


Subflow 1 SDU, ..., Subflow n SDU 


lu-UP-control 


RFCI 


FQC 


Frame Number 


Indication 


lu-UP-payload 


Subflow 1 SDU, ..., Subflow n SDU 


lu-UP-control 


RFCI 


FQC 


Frame Number 


lu-UP-Status 


Indication 


lu-UP-Procedure-Control 


Error Cause, Error Distance 


Complete protocol data for 
Initialisation, Rate Control, Time 
Alignment and Error Event 






Request 


lu-UP-Procedure-Control 


Error Cause 


Complete protocol data for 
Initialisation, Rate Control, Time 
Alignment and Error Event 




lu-UP-UNIT- 
DATA 


Request 


lu-UP-payload 




Indication 


lu-UP-payload 





Primitive usage is function of the mode of operation of the lu UP protocol. Table 2 provides the association between lu 
UP primitives towards the upper layers and the lu UP mode of operation. 

Table 2: lu UP protocol layer service primitives related to the lu UP mode 
of operation and function within the mode of operation 



Primitive 


Type 


Mode of Operation 


lu-UP-DATA 

lu-UP-Status 

lu-UP-UNIT- 
DATA 


Request 


SMpSDU 


Indication 


SMpSDU 


Request 


SMpSDU 


Indication 


SMpSDU 


Request 


TrM 


Indication 


TrM 



7.2.2 lu-UP-DATA-REQUEST 

This primitive is used as a request from the upper layer lu NAS Data Stream entity to send the RAB subflow SDU(s) on 
the established transport connection. This primitive includes the RFCI, the frame number and FQC information of the 
pay load. 

The lu UP Frame protocol layer forms the lu UP data frame, the lu Data Stream DU being the payload of the lu UP 
frame, and transfers the frame by means of the lower layer services. 
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7.2.3 lu-UP-DATA-INDICATION 

This primitive is used as an indication to the upper layer entity to pass the lu NAS Data Stream User Plane information 
of a received lu UP frame. 

This primitive includes the RFCI, the frame number and FQC information of the payload. 

This primitive may also include information aiming at informing the upper layers of a faulty situation that relates to the 
payload included in the primitive. 

7.2.4 lu-UP-STATUS-REQUEST 

This primitive is used to pass procedural information from the upper layer. 

This primitive shall contain the complete protocol data for the respective procedure. 

7.2.5 lu-UP-STATUS-INDICATION 

This primitive is used to pass procedural information to the upper layer. 

This primitive shall contain the complete protocol data for the respective procedure. 

7.2.6 lu-UP-UNIT-DATA-REQUEST 

This primitive is used as a request from the upper layer to send an lu UP payload on the established transport 
connection. 

The lu UP protocol layer transfers the lu Data Stream DU by means of the lower layer services without adding any 
protocol header overhead. 

7.2.7 lu-UP-UNIT-DATA-INDICATION 

This primitive is used as an indication to the upper layer entity to pass the lu UP payload. 

7.3 Primitives towards the transport layers at TNL SAP 

7.3.1 General 

Access to the Transport network Layer is performed through a generic SAP: TNL-SAP. 

When the Transport Network upper layer consists of AAL2, the TNL SAP maps onto the AAL-SAP through which 
communication is performed using specific AAL primitives. 

When the Transport Network upper layer consists of GTP-U, the TNL SAP maps onto the GTP-U SAP through which 
communication is performed using generic primitives. 

The choice of communication, specific or generic, through the TNL SAP is fixed by the Radio Network Layer control 
plane logic. This choice is based on the requirements placed by e.g. the RAB characteristics, the CN domain requesting 
the RAB establishment or other operator's choice. 

7.3.2 ATM/AAL2 based Transport layer 
7.3.2.1 General 

When the lu UP protocol layer uses the services of an ATM/AAL2 transport, it uses an established AAL2 connection 
for transferring frames between the peer TNL-SAPs at both end of the lu User plane access points. The Transport 
Network Control Plane over lu handles the signalling to establish and release the AAL2 call connections. 
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7.3.2.2 AAL2 Service Primitives used by the lu UP protocol 

AAL2 services and primitives used at the Service Access Point from the AAL2 layer are shown in table 3. 

Table 3: AAL2 primitives and parameters 



Primitive 


Type 


Parameters 


Comments 


SSSAR- 
UNITDATA 


Request 


SSSAR-INFO 




SSSAR-UUI 


Not used (note) 


SSSAR- 
UNITDATA 


Indication 


SSSAR-INFO 




SSSAR-UUI 


Not used (note) 


NOTE: The setting of this field is set to not used i.e. decimal value 26 according to [8]. 



The primitives of table 3 are the standard primitives of [8]. These primitives are intended to be used in the lu UP. 

7.3.3 GTP-U based Transport Layer 



7.3.3.1 



General 



When the lu UP protocol layer uses the services of a GTP-U transport, it uses an established GTP-U tunnel for 
transferring frames between the GTP-U tunnel endpoints at both ends of the lu User plane access points. The RANAP 
Control Plane signalling over lu handles the signalling to establish and release the GTP-U tunnels. 

7.3.3.2 Generic Service Primitives used by the lu UP protocol 

Generic primitives are used at the GTP-U SAP. They are shown in table 4. 

Table 4: Generic primitives and parameters to and from GTP-U layer 



Primitive 


Type 


Parameters 


Comments 


lu-UP-UNITDATA 


Request 


lu-UP-payload 




lu-UP-UNITDATA 


Indication 


lu-UP-payload 





8 



Evolution of lu UP Protocol 



8.1 Principles for Protocol Evolution 



8.1.1 



Unknown field value 



The lu UP protocol may be evolved by taking into use field values that have been specified to be reserved for future use 
or have been specified as spare values. When a UP protocol entity receives an unknown field value, it can react 
differently depending whether the unknown value is reserved for future use or if it is a spare value. The following 
principles are recommended for receiver reactions: 

If a spare value is used by the sender, but not understood by the receiver, there should be a default action for the 
receiver. This default action should be defined on a field basis; 

If a value that is reserved for future use is used by the sender, but not understood by the receiver, the value 
should be rejected by the receiver. This should be done by sending a Negative Acknowledgement to the peer 
entity, if possible. Otherwise an Error Event should be generated in order to inform the upper layers and the peer 
entity; 
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A received Error Event message shall not trigger another Error Event message back to the sender, even though 
e.g. the Cause value in the received Error Event message would not be understood. 

In the following the recommended actions of the receiver are handled field by field when an unknown field value is 
received. 

PDU Type 

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause: Unknown PDU Type. 

FQC 

Recommended action if spare values used: Ignore the field and pass it onwards. 

ACK/NACK 

Proposed action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are informed 
about the error event with Cause: Unknown reserved value. 

Procedure Indicator 

Recommended action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause : Unknown procedure 

Error Cause value 

Value 49 is reserved for "lu UP version not supported" whatever the lu UP Mode version. 

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause : Unknown reserved value. 

Recommended action if spare values used: Ignore the field and pass it onwards. 

8.1 .2 Adding a new field to an existing frame 

If there is a need to add a new field to an existing procedure, the following principles shall be applied: 

The PDU type defines the header mask. Therefore, a new field shall not be added to the header part of an 
existing frame and possible spare bits in the header shall not be taken into use since these would be violations of 
the header mask; 

The Procedure Indicator shall define the fields that should be in a control frame; 

There shall be only one Procedure Indicator for each procedure; 

If a new field needs to be introduced to an existing procedure (i.e. existing procedure that is defined in an 
existing UP version), the new field shall not be added to the payload part. Instead, the new field may be 
introduced by placing it to a spare field in the payload part of the frame, if possible; 

However, if a new field needs to be introduced to an existing procedure, but spare fields(s) in the payload part 
cannot be used to introduce the new field, then a new procedure shall be created and hence a new Procedure 
Indicator value shall be allocated for the new procedure; 

To enable simple protocol evolution, when a new Procedure Indicator will be introduced, the new frame shall 
include both the new fields and the fields of the old frame; 

When an implementation receives an unknown Procedure Indicator it may use the Error Event message with 
Cause: Unknown procedure to report this. This indicates to the sender that the procedure was not understood and 
it may try with an older procedure. 

8.1 .3 Adding a new PDU type 

In the future, the lu UP protocol may evolve so that there is a need to add a new PDU type. The criteria for introducing 
a new PDU type could be e.g.: 



£75/ 



3GPP TS 25.41 5 version 4.1 .0 Release 4 52 ETSI TS 1 25 41 5 V4.1 .0 (2001 -06) 



The Procedure Indicators may run out and there is a need to have more; 

There is a need to change the header mask, e.g. the Frame Number field may need to be increased or the CRC 
field needs to be modified. 

While the PDU type 15 is reserved for future PDU type extensions, there may be 'subtypes' under PDU type 15 in the 
future and there also may be new procedures in these 'subtypes'. 

Thus it has to be ensured that if the same Procedure Indicator value is used under several PDU types, it should be made 
clear e.g. in the Error Event cause element, which PDU type it concerns. 

The maximum length of the Spare Extension field is defined per PDU type. Thus when a new PDU type is added, an 
appropriate length for the Spare Extension field (if any) has to be defined. For Release '99, a length of 4 octets has been 
used for data PDUs, and 32 octets for control PDUs. 



8.1 .4 Protocol version handling 



In the future, new versions of the lu UP protocol may be introduced. A reason for a new version of the protocol could 

be, e.g.: 

The earlier introduced new features or functions are required to be mandatory in the new version; 

Due to technical development, the new version of the protocol could be totally different (and incompatible) from 
the earlier version. 

The following principles shall be applied to version handling of lu UP protocol: 

It shall be possible to introduce additional modes of operation; 

It shall be possible to evolve the operation modes independently of each other; 

There shall be independent version numbers for each mode of operation; 

The mode of operation of an lu UP protocol instance is decided by the CN, but the version of the mode shall be 
negotiated between the CN and UTRAN during initialisation procedure; 

The version number of a UP operation mode may change or be unchanged between different releases; 

When the protocol is evolved it shall be made clear in the specification, which features belong to which versions; 

A new version may be an evolution (i.e. compatible) of the old version or the new version may be totally 
different from the old version. 

The structure of the PDU Type 14 header, up to and including header CRC, shall remain unchanged whatever 
the lu UP version. 
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Annex A (informative): 

Illustration of usage of RFC! for AMR speech RAB 

This annex contains information related to usage of RFCIs in the context of AMR speech RAB. 
The following figure illustrates the RFCI allocation and flow throughout the UTRAN. 
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1 . RAB Attributes: at RAB establishment or reconfiguration, the SDU format information parameter is 
passed to UTRAN. The SDU information is organised per BER i.e. RAB sub Flow. For instance, 12,2 
kbits/s AIVIR codec is passed as RAB sub flow 1 SDU size: 81 bits -class A bits-, as RAB sub flow 2 SDU 
size: 1 03 bits -class B bits-, as RAB sub flow 3 SDU size: 60 bits -class C-, which makes one RAB sub 
Flow Combination. This is done for all source rates (i.e. all codec modes, DTX also if included). So using 
the RAB subflows combination set from Table A.I , the SDU Formation Information Parameters for RAB 
subflow 1 is [0,39,39,81], for RAB subflow 2 is [0,0,56,103], and for RAB subflow 3 is [0,0,0,60]. The lu UP 
is used in support mode for predefined SDU size. 

2. Allocation of RFCIs: the RNC dynamically allocates an Identification (RFCI) to each permitted/possible 
combinations it can offer. E.g. for kbits/s, the RNC allocates RFCI 0, for the SID, the RNC allocates RFCI 
1 , for 4,75 kbits/s, the RNC allocates RFCI 2, and for 12,2. kbits/s, the RNC allocates RFCI 3 (according to 
the example table A.I). 

3. Configuration of L2/L3 based on RFCIs: RFCIs are used to configure the L2/L3. RLC is used in 
transparent mode. MAC configures its co-ordinated DCHs with the RFCIs and associates one RFCI to one 
TFI. 

4. Initialisation of lu UP: the RNC reports the permitted combinations It can offer to the transcoder using an 
inband lu initialisation frame containing the RFCIs and associated RAB sub Flow sizes. 

5. Configuration of L2/L3 based on e.g. TFIs: idem as 3. L2/L3 may use e.g. TFI to communicate with the 
Codec about the RAB sub-Flow structure of the SDU received or to be sent. 

6. RFCIS+ SDU size information: the RFCIs and associated RAB sub Flow sizes received within the lu 
initialisation frame are passed to the Codec for configuration. 

7. Example of DL frame transfer: 

7.1 . The Codec encodes a 12,2 kbits/s frame. It sends down to the lu UP an SDU with an associated 
RFCI equals to 3 (in this example). 

The lu UP packs a frame with a header containing an RFCI set to value 3, and the payload made 
of the SDU received from the Codec. 

The lu UP passes to L2/L3, the lu frame payload (the Codec SDU) and the RFCI. The L2/L3 uses 
this RFCI to break the lu frame onto the co-ordinated DCHs corresponding to the different bits 
protection classes. The corresponding TFI is selected. 
The radio frame is sent with the TFCI chosen by MAC. 

The L2/L3 receives the SDUs on the co-ordinated DCHs, combines them back and uses e.g. the 
TFI to indicate to the codec the structure of the received frame. 



7.2. 



7.3. 



7.4 
7.5 



Figure A.I 

For information on RAB subflow combinations used for AMR speech see reference [12]. 
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SRNC allocates one or more possible/available RAB sub-flow combination(s) and generates RAB sub-flow 
combination set. RAB sub-flow combination number is dynamically generated by SRNC. This RAB sub-flow 
combination set is signalled towards CN with user plane signalling as described in [1]. The signalling towards UE is to 
be defined by TSG-RAN WG2. 

RAB sub-flow combination set: 

A RAB sub-flow combination indicator, RFCI, indicates which RAB sub flow combination will be used for the lu user 
frames. In the communication phase the RFCI is included in the user frame, and the RFCI state the structure of the user 
frame. 

Table A.l exemplifies the allocation of 4 different RAB sub-flows combinations for 3 sub-flows and generating of RAB 
sub-flows combination set. 

Table A.l : Example of Allocation of RAB sub-flows combination indicator 





RFCI 
(RAB sub- 
Flow 
Combination 
Indicator) 


RAB sub- 
Flow 1 


RAB sub- 
flow 2 


RAB sub- 
flow 3 


Total 


Source rate 


RAB 
sub- 
flows 
combina 
tion set 

















Source rate 1 


1 


39 








39 


Source rate 2 


2 


39 


56 





95 


Source rate 3 


3 


81 


103 


60 


244 


Source rate 4 


NOTE: In the table above the greyed area shows the part that is sent in the initialisation 
procedure in lu UP. This is what constitutes the RAB subflow combination set. 
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Annex B (informative): 

Illustration of protocol states in the lu UP 

This annex contains information related to possible protocol states for operation of the lu UP. This annex does not 
constraint implementation and is for illustration purposes only. 

The state model is common for both ends of the lu UP so that the protocol machines are operating symmetrically. This 
approach is taken to facilitate state description for all cases including possible future scenarios where the lu UP could be 
terminated elsewhere. 

NOTE: Primitive lu-UP-CONFIG-Req is used by upper layers to configure the lu UP protocol layer. It is used in 
this annex for illustrative purposes and therefore it is not defined in clause 7. 



B.1 Protocol state model for transparent mode 

Figure B.l illustrates the state model for transparent mode lu UP instances. A transparent mode instance can be in one 
of following states. 

lu-UP-CONFIG-Req 



lu-UP-UNIT-DATA-Req or 
lu-UP-UNIT-DATA-Ind or 
SSSAR-UNITDATA-Req or 
SSSAR-UNITDATA-Ind or 
lu-UP-UNITDATA-Ind or 
lu-UP-UNITDATA-Req 



lu-UP-CONFIG-Req 

Figure B.l : Protocol state model for transparent mode 



B.1.1 Null State 

In the null state the lu UP instance does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a lu-UP-CONFIG-Req from higher layer the lu UP instance is created and transparent mode data 
transfer ready state is entered. The mode information is received either through RANAP signalling or directly in the CN 
node. In the lu-UP-CONFIG-Req e.g. the following information will be indicated: 

Transparent mode. 

B.1 .2 Transparent Mode Data Transfer Ready State 

In the transparent mode data transfer ready state, transparent mode data can be exchanged between the entities. 

Upon reception of lu-UP-CONFIG-Req indicating release from higher layer, the lu UP instance is terminated and the 
null state is entered. 
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B.2 Protocol state model for support mode for predefined 
SDU sizes 

Figure B.2 illustrates the state model for support mode lu UP instances. A support mode instance can be in one of the 
following states. 



lu PDU ► 

Primitive between layers ► 



lu-UP-CONFIGKSq^InitialisationTjjjfjgjjj^fjQjj 

WRepeat) 



Last Initialisation 

,ACK sent or 
Last Initialisation 
Ack received 




lu-UP-CONFIGReq 



lu-UP-STATUSIndV 
(Rate control) 



Rate controP 
PDU 



lu-UP-DATAReqor 

lu-UP-DATAIndor 

SSS AR-UNITDATAReq or 

SSS AR-UNITDATAkid or 

lu-UP-UNITD ATAInd or 

lu-UP-UNITDATAReq 



Figure B.2: Protocol state model for support mode 



B.2.1 Null State 

In the null state the lu UP instance does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a lu-UP-CONFIG-Req from higher layer the lu UP instance is created and initialisation state is 
entered. In the lu-UP-CONFIG-Req e.g. the following information could be indicated: 

Support mode for predefined SDU sizes; 

Time alignment (FFS); 

Indication of delivery of erroneous SDUs; 

- Periodicity. 

B.2.2 Initialisation State 

In the initialisation state the instance exchanges initialisation information with its peer lu UP instance. 

Upon reception of lu-UP-CONFIG-Req indicating release from higher layer, the lu UP instance is terminated and the 
null state is entered. 
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Upon sending or receiving of an initialisation frame the lu UP instance remains in the Initialisation state. The sending 
side starts a supervision timer Tinit- The receiving side acknowledges the initialisation frame with a positive 
acknowledgement or a negative acknowledgement. 

Upon reception of the last initialisation acknowledgement frame, the supervision timer T^it is stopped and the lu UP 
instance enters SMpSDU data transfer ready state. 

After sending a positive acknowledgement of the last initialisation frame, the lu UP instance enters SMpSDU data 
transfer ready state. Note that CN does not know if the initialisation ACK was correctly received by the RNC (and 
initialisation procedure successfully completed) until it receives RAB assignment response, or use data from the RNC. 
The CN must therefore be able to continue receiving initialisation frames by re-entering the Initialisation state (from 
Support Mode Data Transfer Ready State), if the CN has started to send user data before receiving the indication that 
Initialisation was successfully completed. 

Upon reception of an initialisation negative acknowledgement frame (INIT NACK) initialisation frame can be repeated 
n times. 

If after n repetitions, the initialisation procedure is unsuccessfully terminated (due to n negative acknowledgements or 
timer expires) the Error event procedure is used to report the Initialisation failure and the lu UP instance remains in the 
initialisation state. Upon reception of an Initialisation frame the Initialisation state is entered. 

B.2.3 Support Mode Data Transfer Ready State 

In the support mode data transfer ready state, support mode data can be exchanged between the peer lu UP instances. 

Upon reception of lu-UP-D ATA-Request from the upper layer or SSSAR-UNITDATA-Indication or 
lu-UP-UNITDATA-Indication from TNL layer, appropriate user data transfer procedures are performed. lu UP instance 
remains in the SMpSDU data transfer ready state. 

Upon sending of lu-UP-DATA- Indication or SSSAR-UNITD ATA-Request or lu-UP-UNITD ATA-Request the lu UP 
instance remains in the SMpSDU data transfer ready state. 

Upon sending or receiving of a rate control PDU the lu UP instance remains in the SMpSDU data transfer ready state. 

Upon sending of a lu-UP-STATUS-Indication (rate control) the lu UP instance remains in the SMpSDU data transfer 
ready state. 

Upon reception of lu-UP-CONFIG-Req from higher layer the lu UP instance is terminated and the null state is entered. 

Upon detection of a protocol fault, lu-UP-STATUS-Indication is sent to upper layer an error event frame may be sent 
over lu UP. 

In case of handover or relocation, initialisation procedures may have to be performed and lu UP instance may have to 
enter the initialisation state. 
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Annex C (informative): 
Open Issues of the lu UP 

This annex contains information related to open issues left in the lu UP protocol. 
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Annex D (informative): 

Distributed rate decision within RNC 

This annex contains information related to the distributed rate decision within an RNC (see also within [13]) 

The rate control procedure over lu UP is normally controlled by the entity controlling the rate control over UTRAN i.e. 
the SRNC. The SRNC may send rate control commands in uplink (to the CN) to control the rates in downlink. The 
SRNC may also send rate control commands in downlink (to the UE) to control the rates in uplink. The rate control 
procedures for both directions are independent of each other, i.e. different rates may be permitted in uplink and 
downlink, see Figure D.l. 



UE 



SRNC 



Rate Control for uplink 



User Data with uplink Rates 



User Data 



CN 



User Data 



Rate Control for downlink 



User Data with downlink Rates 



Figure D.l : Rate Control for uplink and downlink 

The rates associated with the service could be rank ordered from "lower" to "higher" according to their SDU bit rates 
and RFCI values, with RFCI=0 having the lowest rate. A rate lower than the currently allowed maximum rate shall not 
be forbidden while a higher rate is forbidden. In order to stabilise the rate control procedure and its influences on the 
radio link and the network, typically only one additional rate shall be forbidden or permitted in subsequent rate control 
commands. 

In some cases, as TrFO and TFO, the rate is also controlled by the remote partner at the other end of the lu UP. The 
SRNC may then also receive rate control commands in downlink (from the CN) controlling the rates in uplink. Only 
rates that are permitted by both sides for one direction shall be used in that direction. The SRNC shall therefore 
combine these rate commands from the CN with its own control commands for the uplink direction by taking the rate 
control command with the lowest maximum rate and shall sent this rate control command downlink to the UE. This 
combination is denoted in Figure D.2 with "Rate Control (CN ® RNC)". 



UE 




SRNC 




CN 




R 


ate Control (CN ® RNC) for 


uplink 


R 


ate Control (CN) for uplink 








User Data with (CN © RNC) Rates 


User Data 






w 
User Data 
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Figure D.2: Distributed Rate Control for uplink and downlink 
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